Date: Tue, 17 Aug 93 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #242
To: packet-radio


Packet-Radio Digest         Tue, 17 Aug 93       Volume 93 : Issue  242

Today's Topics:
                          Digital Hierarchy
                        International Software
          Need freqs. for 70cm LANs in ATL/north GA (2 msgs)
                    Settings for Baypac & IC24AT?
                              Small TNC?

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 16 Aug 93 14:07:23 GMT
From: ogicse!emory!dragon!nj8j!ben@network.ucsd.edu
Subject: Digital Hierarchy
To: packet-radio@ucsd.edu

Kenneth.E.Harker@Dartmouth.Edu (Kenneth E. Harker) writes:

>       It would seem to me that a sensible solution to the digital
> hierarchy problem would be for someone to start the voting process for
> groups like:
> 
> rec.radio.amateur.digital.packet
> rec.radio.amateur.digital.tcpip
> rec.radio.amateur.digital.rtty
> rec.radio.amateur.digital.pactor
> rec.radio.amateur.digital.equipment
> 
> etc...
> 
> This is the logical hierarchy, and most probably the reason that
> rec.radio.amateur.digital.misc won the vote.  This is similar to when
> the rec.ham-radio hierarchy was changed to rec.radio.amateur.  It will
> make more sense in the long run.  All that is necessary is for the rest
> of the newsgroups to get created.

Of course, the question will be(consider this a preview of what the 
discussion will look like in news.groups when this RFD gets cranking in a 
few months):  is there sufficient traffic to justify the new groups?  
Obviously, there will be another try at creation of rrad.tcpip.  Based
on what I've seen recently, rrad.packet will probably be in the running 
also.  But is there really enough RTTY, AMTOR, or PACTOR traffic on here to 
justify a separate newsgroup for them?  In the end, I think they will be 
left to rrad.misc until enough long-term traffic shows up to justify 
creating separate groups.

Ben


+---------------------------------------+---------------------------------+
| Ben Coleman NJ8J                      | "All that is not eternal is     |
| AX.25:  NJ8J@W4QO.#EAL.#ATL.GA.USA.NA |          eternally irrelevant." |
| Internet: ben@nj8j.atl.ga.us          |                     C. S. Lewis | 
+-------------------------------------------------------------------------+ 

------------------------------

Date: 16 Aug 1993 07:03:52 +0200
From: news.univie.ac.@!alijku11!aci.cvut.cz!rhino.cis.vutbr.cz!rhino.cis.vutbr.cz!not-for-mail@uunet.uu.net
Subject: International Software
To: packet-radio@ucsd.edu

Please share your expertise with our mailing list.


INSOFT-L on LISTSERV@CIS.VUTBR.CZ   Internationalization of Software
                                    Discussion List

   Internationalization of software relates to two subjects:

        1. Software that is written so a user can easily change the
           language of the interface;

        2. Versions of software, such as Czech WordPerfect, whose
           interface language differs from the original product.

   Topics discussed on this list include:

        -- Techniques for developing new software

        -- Techniques for converting existing software

        -- Internationalization tools

        -- Announcements of internationalized public domain software

        -- Announcements of foreign-language versions of commercial
           software

        -- Calls for papers

	-- Conference announcements

	-- References to documentation related to the
           internationalization of software
	
   This list is moderated.

   To subscribe to this list, send an electronic mail message to
   LISTSERV@CIS.VUTBR.CZ with the body containing the command:

      SUB INSOFT-L Yourfirstname Yourlastname

   Owner:

      Center for Computing and Information Services
      Technical University of Brno
      Udolni 19, 602 00 BRNO
      Czech Republic

      INSOFT-L-REQUEST@CIS.VUTBR.CZ

------------------------------

Date: Mon, 16 Aug 93 20:41:10 CDT
From: swrinde!gatech!howland.reston.ans.net!agate!iat.holonet.net!vulcan!kd4cim@network.ucsd.edu
Subject: Need freqs. for 70cm LANs in ATL/north GA
To: packet-radio@ucsd.edu

larryk@mom.computone.com (larry kollar) writes:

> 	[I sent this last week, but it apparantly got munched in
> 	 a power failure.  Ignore if you have already seen this.]
> 
> The subject says it all.  I *really* want 9600 baud LANs, but would appreciat
> hearing of others.  I'd also like to know where the 56K frequencies are, just
> so I can avoid QRM'ing them. :-)
> 

The 56 kbps frequencies in GA, ALA and TN are all in the 220 band.  In 
the ALANET 56 kbps network, we use 223.850.  I am not sure what GRAPES 
uses.  Contact Bruce Nebergall at k4tql@k4tql.ga.usa.na

The 56kb signalls are 70 khz wide and cannot be even be detected by any 
radio that I know of.  The only method that I have used to even detect 
the signal is using a spectrum analyzer and even then the signal is so 
fast that it is hard to see unless there is a file xfer between 56kb 
systems going on.

There was a fellow in the packet demo room at the Huntsville Hamfest that 
had a spectrum analyzer and wanted to see the signal.  He asked for 
someone to do a nodes list and was very surprised to not even see it go 
by.  Let's see: 500 byte long node list / 7000 bytes/sec.  The longest 
signal is the carrier bring up time.

If you weren't at HSV, you missed a fine packet demo/forum.  There was
the 56kb stuff, 9600 baud modems/radio mods, TCP/IP.  After the 9600 baud 
forum, at least 4 9600 modems were bought by folks from ALANET, so expect 
some action there real soon.  (One of them goes on the 56kb switch in
Birmingham).  And one on my station, heh heh.

Speaking of HSV, I want to congratulate Bob Shaefer, 
ka4pkb@k4ry.al.usa.na or rlsnsdl@eng.auburn.edu for coordinating the fine 
showing at HSV.  His work resulted in some outstanding demos and forums.


de Jerry

BHM AmprNet  - kd4cim@kd4cim.ampr.org  [44.100.113.19]
Packet Radio - KD4CIM @ KD4CIM.AL.USA.NA
Internet     - kd4cim@vulcan.com

------------------------------

Date: Mon, 16 Aug 93 21:54:03 CDT
From: usc!howland.reston.ans.net!agate!iat.holonet.net!vulcan!kd4cim@network.ucsd.edu
Subject: Need freqs. for 70cm LANs in ATL/north GA
To: packet-radio@ucsd.edu

larryk@mom.computone.com (larry kollar) writes:

I know the subject says it all.  But why do you associate 9600 baud with 
70cm?  (I missed that in my first reply).  19,200 is OK on 2M as far as 
the FCC is concerned.

56kb is the next step on 220 and 440.  On 900 mhz and above, I think it 
is pretty well whatever you can devise as long as the signal doesn't go 
out of band.

There is a "traditional" relationship between bits/second and baud.  
However, they ain't really the same (I am talking the signalling level, 
not stuff like V.42bis compression).  I ask Gary Coffman at Destructive 
Testing Systems to comment on the bits/sec vs baud.

Also, pls start posting the kind of stuff to 'r.r.a.d.m' instead of 
'r.r.a.p' since r.r.a.p is going away.  What is the date?  9/21/93?


de Jerry

BHM AmprNet  - kd4cim@kd4cim.ampr.org  [44.100.113.19]
Packet Radio - KD4CIM @ KD4CIM.AL.USA.NA
Internet     - kd4cim@vulcan.com

------------------------------

Date: 16 Aug 93 19:01:18 GMT
From: ogicse!uwm.edu!cs.utexas.edu!convex!constellation!essex.ecn.uoknor.edu!news@network.ucsd.edu
Subject: Settings for Baypac & IC24AT?
To: packet-radio@ucsd.edu

In article <BAT.93Aug15142156@gdstech.GRUMMAN.COM> bat@gdstech.GRUMMAN.COM (Pat Masterson) writes:
>You didnt say what kinds of lockups you had. But, they might
>not be from a parameter problem at all. More likely RF from your
>radio is getting into your computer, and killing it. This is a very
>common problem, even with ATs, but easily solved. Ground everything
>(radio, 486, TNC if metal),  and put ferrites on all the cables, and
>your antenna coax. I'll bet the problem goes away.

It doesn't lock up, and, in fact, it may be working fine, but I get 
more retries and connect failures than I'd like. It may just
be the setup. It seems to hear fine. For example, I'll copy stuff
sent by an Oklahoma City BBS just fine, but can't connect with
it. 

One approach is an A/B test where everything is the same (radio,
computer, settings, etc.) except use the Baypac with Baycom 
instead of my PK232 (which I normally use with a base rig)
with, say, PC-Pakratt. However, I didn't really want to
make up a set of cables to hook my HT up to the PK232,
especially since this is a combination I'm not going to want to
use often, if ever.

Basically I was hoping somebody would say "Oh, yeah, I had trouble
connecting with stations when I used the default settings in Baycom
but when I changed the framistat setting to 75 quarks [or turned 
the volume on the 24AT to blah, blah, blah;  or turned the level control
on the Baypac to blah, blah, blah] I suddenly could connect to BBSs on 
Jupiter." In other words a) I'm lazy and b) I was hoping for a miracle!

Thanks, anyhow, for your reply, and I will explore the RFI possibility.
 
+--------------------------------------------------------------------+
| Jud Ahern KC5RI             Internet: jahern@geohub.gcn.uoknor.edu |
| Geology & Geophysics        Bitnet: jahern@uokgcn.bitnet           |
| University of Oklahoma  "Opinions expressed here reflect the entire|
| Norman, OK  73019        University, in one convenient location."  |
+--------------------------------------------------------------------+

------------------------------

Date: 16 Aug 93 12:46:23 EST
From: titan.ksc.nasa.gov!k4dii.ksc.nasa.gov!user@ames.arpa
Subject: Small TNC?
To: packet-radio@ucsd.edu

In article <Aug03.223816.25137@acs.ucalgary.ca>,
trond@smith.phys.ucalgary.ca (Trond Trondsen) wrote:
> I would like to go portable on packet and now I wonder what is the (physically)
> smallest TNC available?

Trond-

I have both the Heath HK-21 and the Pac-Comm HandiePacket TNC's.  They each
have internal NiCd batteries, and draw only a few milliamps.

The HK-21 has absolutely no shielding, so you can't use it anywhere near
the receiving antenna.  The hash it puts out makes use with a nearby
handheld transceiver nearly impossible, except with the strongest signals. 
It also has an internal oscillator with a harmonic near 145.01 MHz.

The Pac-Comm HandiePacket is fairly well shielded, and would probably be
just what you're looking for, although slightly larger than the Heath. 
Pac-Comm is located in Tampa, Florida, but I don't have an address handy.

I understand the Russian Space Station MIR, is using a Pac-Comm
HandiePacket TNC.  (They were recently heard on 145.550, using
R0MIR/R0MIR-1 call letters on packet, and "Space Station MIR" on voice.)

73, Fred, K4DII

------------------------------

End of Packet-Radio Digest V93 #242
******************************
